1. Field of the Invention
This invention is related to the field of processors and, more particularly, to register renaming mechanisms within processors.
2. Description of the Related Art
Superscalar processors attempt to achieve high performance by dispatching and executing multiple instructions per clock cycle, and by operating at the shortest possible clock cycle time consistent with the design. To the extent that a given processor is successful at dispatching and/or executing multiple instructions per clock cycle, high performance may be realized.
One technique often employed by processors to increase the number of instructions which may be executed concurrently is speculative execution (e.g. executing instructions out of order with respect to the order of execution indicated by the program or executing instructions subsequent to predicted branches). Often, instructions which are immediately subsequent to a particular instruction are dependent upon that particular instruction (i.e. the result of the particular instruction is used by the immediately subsequent instructions). Hence, the immediately subsequent instructions may not be executable concurrently with the particular instruction. However, instructions which are further subsequent to the particular instruction in program order may not have any dependency upon the particular instruction and may therefore execute concurrently with the particular instruction. Still further, speculative execution of instructions subsequent to mispredicted branches may increase the number of instructions executed concurrently if the branch is predicted correctly.
Out of order execution gives rise to another type of dependency, often referred to as an "antidependency". Generally, antidependencies occur if an instruction subsequent to a particular instruction updates a register which is either accessed (read) or updated (written) by the particular instruction. The particular instruction must read or write the register prior to the subsequent instruction writing the register for proper operation of the program. Generally, an instruction may have one or more source operands (which are input values to be operated upon by the instructions) which may be stored in memory or in registers. An instruction may also have one or more destinations (which are locations for storing results of executing the instruction) which may also be stored in memory or in registers.
A technique for removing antidependencies between source and destination registers of instructions, and thereby allowing increased out of order execution, is register renaming. In register renaming, a pool of "rename registers" are implemented by the processor. The pool of rename registers are greater in number than (i) the registers defined by the instruction set architecture employed by the processor (the "architected registers") and (ii) the registers employed for temporary use, such as by microcode routines (the "temporary registers"). Together, the architected registers and temporary registers are referred to as the "logical registers". The destination register for a particular instruction (i.e. the logical register written with the execution result of the instruction) is "renamed" by assigning one of the rename registers to the logical register. The value of the logical register prior to execution of the particular instruction remains stored in the rename register previously assigned to the logical register. If a previous instruction reads the logical register, the previously assigned rename register is read. If a previous instruction writes the logical register, the previously assigned rename register is written. Accordingly, the rename registers may be updated in any order.
Register renaming may also allow speculative update of registers due to instruction execution subsequent to a predicted branch instruction. Previous renames may be maintained until the branch instruction is resolved. If the branch instruction is mispredicted, the previous renames may be used to recover the state of the processor at the mispredicted branch instruction.
In many instruction set architectures, a variety of architected registers are provided for storing instruction results of varying types. For example, integer, floating point, multimedia, and condition code registers may be defined. Integer registers are employed for storing integer values (i.e. whole number values represented by the magnitude of the value stored in the registers). Floating point registers are employed for storing the floating point values (i.e. numbers represented by a sign, exponent, and significand stored in the register). Multimedia registers are used for storing multimedia values (e.g. packed integer or floating values representing audio and video information, operated upon in a single instruction, multiple data (SIMD) fashion). Finally, condition code registers store values which indicate the result of a particular manipulation (e.g. zero, greater than or less than zero, carry out) or comparison (e.g. equal, greater than, less than). Condition codes may also be referred to herein as "flags".
Each of the various types of registers may have a different size than the others. For example, in the x86 instruction set architecture, floating point registers are 80 bits wide, multimedia registers are 64 bits wide, integer registers are 32 bits wide (and subdivided into independently addressable portions), and the condition codes are stored in an EFLAGS register but comprise 6 bits. Accordingly, processors typically rename each register type separately with register renames of the corresponding size. Unfortunately, rename registers of a particular type may be idle if instructions manipulating that type are not being executed. For example, floating point renames are idle if floating point instructions are not being executed. The total amount of available rename register space may therefore by inefficiently used much of the time.
Furthermore, in the x86 instruction set architecture many integer instructions update both a destination and the condition codes. Therefore, multiple rename registers may need to be assigned to each instruction. Register rename logic complexity may therefore be significant. Accordingly, a more efficient and simpler register rename scheme is desired.